Method and system for providing teleassistance services based on software agents executing workflows

ABSTRACT

A system for performing a teleassistance service, for example, in the medical field, comprising a central system for controlling and managing the service, a local system for performing the service, and a telecommunication network adapted to communicate the central system with the local system, wherein the local system includes at least one sensor adapted to perform measures of at least one biomedical parameter on a user and a terminal adapted to communicate with the sensor for receiving information related to measure results and adapted to transmit said information to the central system through the telecommunications network, and wherein at least one between the terminal and the central system includes a software agent provided with a process engine for executing workflows, said agent being adapted to interact with the sensor when executing workflows.

TECHNICAL FIELD OF THE INVENTION

The present invention is related to a method and a system for performingteleassistance services for applications linked to health and wellnessof people, herein below called “healthcare” and “wellness” services.

PRIOR ART

Healthcare and wellness services have a high complexity in terms ofinvolved actors, apparatuses that can be used and processes underlyingthe delivery of services.

Nowadays, information systems in healthcare environments arecharacterised by a high complexity, since they must support theplurality of involved actors, manage numerosity and non-uniformity ofused apparatuses, govern services creating and delivering processes, andallow customising the services for all users.

Moreover, in many cases, the evolution of information systems inhealthcare environments resulted in the creation of scarcely mutuallyintegrated application islands, even within a single organisation (forexample hospital departments and medical first aid stations).

For these reasons, the creation of new services or functionalities islimited in terms of integration with existing solutions, scalability(namely capability of supporting services that can involve a high numberof actors) and flexibility (namely capability of responding to differentneeds that can dynamically occur).

Moreover, nowadays, systems and methods used for healthcare and wellnessservices are mainly based on solutions with architectures of theclient-server type, in which service logic and arrangement areimplemented on a centralised software application (server) thatcoordinates and manages distributed hardware and software resources(client).

In literature there are also some solutions based on Agent Systems orMulti Agent Systems (MAS). Such solutions use distributed architectureswith different types of software agents to which defined roles and tasksare assigned. Service logic and arrangement are demanded to the specificprogramming of a component (for example being itself an agent) whosetasks are activating, controlling and administering architecture agentsin order to reach the service objective.

Some solutions analysed in the prior art use, in addition to agents,also “workflows”. In such case, agents' roles and tasks are predefineddepending on initial design and their programming (for example “chronicpatient agents” or “medical agents” are defined). The workflow componentis used for assigning in a centralised way tasks and objectives toagents depending on their pre-defined behaviour.

Herein below some known teleassistance solutions are mentioned.

US2006/0089853A1 is related to a system and a method for allowing usersto communicate and share data with service providers, focusing theirattention on the case in which users are patients and service providersare Health Care Professionals (HCP) and the system is used for remotehealth care monitoring. The solution key points are:

a method for generating clinical protocols, comprising the steps thatthe patient must perform by selecting generic clinical protocols, whichmust be specialised for the particular clinical case by theprofessionals;

a method for sharing data between customers and the plurality ofprofessionals by subscribing data related to related patient's clinicalprotocols;

a method for transmitting the protocol to the patient's apparatus andfor locally executing it through a “bootstrap”;

an editor for generating generic protocols that are stored in adedicated “protocol memory”.

Articles L. M. Camarinha-Matos and H. Afsarmanesh, “TeleCARE:Collaborative virtual elderly support communities”, in Proceedings ofthe 1st Workshop on Tele-Care and Collaborative Virtual Communities inElderly Care, TELECARE 2004, and L. M. Camarinha-Matos, Joao Rosas,Ana-Ines Oliveira, “A Mobile Agents Platform for Telecare andTeleassistance”, in Proceedings of the 1st Workshop on Tele-Care andCollaborative Virtual Communities in Elderly Care, TELECARE 2004,describe a system (called Telecare) comprising a platform (framework)for creating and delivering eHealth services dedicated to elderly peopleand virtual communities of elderly people.

Such platform is based on using stationary agents and mobile agents; theMAS (Multi Agent System) platform provides methods and tools forcreating, transmitting, receiving, authenticating, validating, executingand interacting with agents, and also perform the management of healthdata and system information (catalogue of devices and services).Moreover, every specific service is implemented by using, in differentways, a set of stationary and mobile agents.

Article Mihaela Ulieru (Electrical and Computer Engineering Department,The University of Calgary), “Internet-enabled soft computing holarchiesfor e-health applications—Soft Computing Enhancing the Internet and theInternet Enhancing Soft Computing”, available onhttp://isg.enme.ucalgary.ca/People/Ulieru/Default.htm site, proposes anextension of the holarchy paradigm (hierarchic system of entities thatcan mutually cooperate) from company to health environments. Holarchiesin health environment are a system of health entities (ex. patients,doctors, medical devices, hospitals, pharmacies, etc.) that worktogether for realising services. The proposal provides for implementing“holons” through agents, and the concept of mediator agent is introducedfor managing the fact that an entity can in turn be composed of otherentities. Moreover, a fuzzy-evolutionary approach is introduced, throughwhich the different entities are organised in order to make clusters ofentities and new iteration modes emerge, through which the objective tobe reached is better confronted (ex. request of diagnosis by thepatient). This ensures that the holarchy goal is reached by reaching thesub-goals of individual entities. This article shows two alternativeimplementations of medical holarchy. In the first one, dominion actorsare realised through web-services and dominion functions are mapped inindividual methods stated by the related web-service. The mediator roleis performed by a centralised workflow manager (web services manager).In the second one, dominion actors and mediator are realised throughsoftware agents with FIPA specification. In this case it is the mediatorthat manages interactions between agents and not the workflow manager.

Article L. Ardissono, A. Di Leva, G. Petrone, M. Segnan, M. Sonnessa(Dipartimento di Informatica, University di Torino, “Adaptive MedicalWorkflow Management for a Context-Dependent Home Healthcare AssistanceService”, CWS 2005 Preliminary Version, available onwww.di.unito.it/˜liliana/EC/CWS05.pdf Internet site, describes aframework for offering supporting services to actors (patients, doctors,nurses, . . . ) of home health assistance. The home assistance servicein general is aimed for elderly and chronic patients, that are usuallyaffected by more than one pathology and must therefore be subjected tomore than one medical protocol (depending on the number of pathologies).The proposal provides that actors involved in home assistance servicecan interact with some computers (desktop, laptop, PDA, . . . )connected to a network (mobile and/or fixed one).

The proposed framework architecture is based on integrating web servicesand autonomous agent technologies in order to improve and customise theexecution of medical guidelines (treated as abstract workflows) byexecuting context-based actions. The proposed system allows settingthrough web different medical guidelines to which a patient must besubjected, the guide to actions that actors (doctors, nurses, patient)must perform to implement the guidelines.

Article David Isern and Antonio Moreno (Departament d'EnginyeriaInformàtica i Matemàtiques. Universitat Rovira i Virgili), “Agent-basedcareflow using CPGs”, available onhttp://www.etse.urv.es/recerca/rgai/toni/MAS/Publicacions/ccia04dia.pdfsite, proposes to use an agent-type platform for managing andcoordinating human resources and materials involved in hospital careprocesses. The proposed system is an evolution of the HeCaSe (HealthCare Service) solution, always based on MAS (Multi-Agent System) anddescribed in the previous article. In this solution, all involved actorsare modelled through agents implementing individual behaviours and that,by mutually interacting, emulate real processes of a health system. TheHeCaSe system allows a patient to have information about servicesoffered by nearest medical centres, to reserve specialist visits througha negotiation process with the chosen doctor. Health personnel hasfurther the chance of flexibly and efficiently organising their ownworking time, and appointments with patients. Finally, patients'clinical information can be accessed by patients themselves andauthorised health personnel that can also update them following aclinical examination or a specialist visit. The main news proposed inthis article with respect to the original HeCaSe solution deals with thechance of using agents to help doctors follow the Clinical PracticeGuidelines (CPG). The CPG are clinical protocols associated with everysingle pathology. The objective is that, in the HeCaSe solution, the CPGare automatically embedded in medical and hospital services workflows.In this way, the CPG become part of appointment or services negotiationprocesses between patients, doctors and health structures. The CPG use aformal language called PROforma that is able to be executed by acomputer.

These articles in general integrate the concepts of workflow andautonomous agent in a mode, present in literature, that consists inusing the workflows for scheduling single activities/tasks that mustthen be coded within agents or within web services.

PURPOSE AND SUMMARY OF THE INVENTION

The Applicant has observed that the previously described known art hasthe problem of a scarce flexibility and interactivity with users.

For example, in US2006/0089853A1 the only interaction between users andsystem is through reading/writing information inside pre-establishedprotocols.

In the other cited documents, the individual tasks that agents are ableto perform must always be realised through code and implemented atplatform design level.

The Applicant has thereby dealt with the problem of providing aparticularly functional and interactive teleassistance technique,particularly adapted to also manage situations with scarce capability ofusers in actively interacting with the system, for example in case ofpatients with severe illnesses or handicapped.

The Applicant has found that a teleassistance service with suchcharacteristics can be realised by pre-arranging sensors of biomedicalparameters to be used by users, and software agents that are able tointeract with the sensors during measures execution; such agents areequipped with process engines adapted to execute workflows thatimplement the chosen teleassistance service logic (every service beingdefined by one or more workflows), in order to be then able to provideusers with information or instructions related with detected parameters.In such a way, it is possible to implement interactive assistanceservices with procedures for detecting the health status realisedthrough the biomedical sensors. The system can further be integratedwith environment sensors and/or with the Telco functionality forlocating or detecting the presence of users provided for increasing theassistance service functionality.

The above software agent is preferably loaded in a terminal used by theuser or service personnel, and the terminal is able to communicate withthe biomedical sensor (namely it is provided with a gatewayfunctionality towards the sensor), for example with a bluetoothconnection. The terminal is further able to communicate, through atelecommunications network, with a remote centre (in particular acentral system platform), in which the functionalities of creating,storing and deploying the workflows are centralised, in addition tocreating and managing the agents. The remote centre can further beinterfaced with a services centre, in which specialised personnel can beplaced, in turn provided with terminals with agents and workflowengines, for remote diagnosis, monitoring and consultancy activities,always based on data that are locally detected by sensors.

According to a first aspect thereof, the present invention therebyrefers to a method for performing a teleassistance service, comprising:

executing a measure of at least one biomedical parameter on a serviceuser;

executing, through a software agent, at least one workflow associatedwith the service and defining a process interactive with the measureexecution.

Advantageously, the method provides for transmitting information relatedto the result of the measure to a remote system through atelecommunications network.

The method can further provide the user with a feedback based on theresult of the measure.

The measure is preferably performed by a sensor used by the user.

The step of transmitting information related to the result of themeasure to a remote system can comprise communicating information fromthe sensor to a terminal and then transmitting information from theterminal to the remote system through the telecommunications network.

The software agent can be in the terminal; alternatively, the softwareagent can be in the remote system.

The method can further comprise the preliminary steps of defining theworkflow in order to implement a service logic, and storing the workflowin a database.

The method can also comprise the steps of receiving a service request bya user, and executing, in reply to the service request, a serviceactivation workflow in a software agent.

Executing an activation workflow can comprise selecting the workflowassociated to the service among a plurality of available workflows,depending on information contained in the service request.

Moreover, executing an activation workflow can comprise transmitting theselected workflow to the terminal.

Executing the activation workflow can also comprise configuring theterminal in order to make it suitable for executing the selectedworkflow.

If the software agent is in the terminal, the step of configuring theterminal can comprise activating the software agent in the terminal andactivating a connection between the terminal and the sensor.

Such connection can also be of the bluetooth type.

The method can also comprise the step of executing a measure of at leastone environment parameter related to an environment in which the user islocated; in such case, the process defined by the workflow can beinteractive also with the execution of the measure of the at least oneenvironment parameter.

In addition or alternatively, the method can also comprise the furtherstep of executing a user location measure; in such case, the processdefined by the workflow being interactive also with the execution of thelocation measure.

In a further aspect thereof, the present invention is related to asystem for executing a teleassistance service, comprising:

a central service controlling and managing system;

a local service executing system; and

a telecommunication network adapted to communicate the central systemwith the local system;

wherein the local system comprises at least one sensor adapted toperform measures of at least one biomedical parameter on a user and aterminal adapted to communicate with the sensor for receivinginformation related to the measure results;

and wherein at least one between the terminal and the central systemcomprises a software agent provided with a process engine for executingthe workflow, said agent being adapted to interact with the sensor whenexecuting the workflow.

Advantageously, the terminal is adapted to transmit information relatedto measure results to the central system through the telecommunicationsnetwork.

The terminal can comprise the above agent and a graphic interfacethrough which the user can interact with the workflows.

The terminal can further comprise a device gateway for communicatingwith the sensor.

The terminal and the sensor can be adapted to mutually communicatethrough a wireless connection.

Such connection can be of the bluetooth type.

The central system can further comprise a graphic representation systemfor creating workflows.

The central system can also comprise a data storage system for storingworkflows and results of said measures.

Moreover, the central system can comprise a plurality of workflowexecuting agents, each agent comprising a process engine for executingworkflows.

The central system can further comprise adapters for interfacing theplurality of workflow executing agents with the telecommunicationsnetwork, depending on the used transmission protocol.

Moreover, the central system can comprise a workflow deploying agent.The local system can comprise at least one environment sensor adapted tomeasure an environment parameter, said agent being adapted to interactwith the environment sensor when executing workflows.

The system of the present invention can further comprise a locatingsystem adapted to provide user location information, said agent beingadapted to interact with the locating system when executing workflows.

Moreover, the system of the present invention can comprise at least onefurther terminal adapted to communicate with said terminal through thecentral system and the telecommunications network.

The above sensor can be integrated in the terminal. The terminal can bea cellular phone.

An important characteristic of the present invention is that thesoftware agent is equipped with a workflow engine that allows it toexecute, in a dynamic and flexible way, workflows and subflows (orportions of workflow) that describe the task and the behaviour of theagent for a particular service. Individual agents are therefore able toexecute tasks corresponding to portions of workflow, that can be updatedthrough platform provisioning functionalities. In such a way, it is notnecessary to program, at design level, the agents by pre-assigning rolesand tasks to them. Agents are therefore more open to modify their ownbehaviour (roles, tasks and activities) depending on what is implementedin the workflow. Moreover, it is possible to quickly create the servicessince it is enough to implement the service logic inside the workflowand not on various types of distributed agents. The flexibility providedby designing the workflows allows having highly re-usable components andagents and allows configuring the agents also at runtime of processes tobe executed.

The use of agents further allows having a computing and decisionalcapability that is distributed in various system nodes (for example atdevice or gateway level) and the used workflow solution allowscoordinating it. Such aspect allows distributed agents to be autonomousand proactive upon the occurrence of an event and to be able to executecomputations or take decisions at system node level. In particular,workflows are arranged for reacting to external events such as theautomatic measure of vital patient parameters (ex. pressure, alcoholrate, glycaemia rate, etc.) and communicating in general with thesensors.

The use of the described solution allows having the following furtherdifferentiating elements:

definition and giving parameters to the workflows are executed throughan evolved editor and provided as functionality to system users (forexample medical personnel); it is therefore possible to simply (and alsodynamically) define workflows implementing specific services for groupsof users or for a single patient;

the system comprises a centralised repository of processes that can beactivated (namely executed by agents) on the platform, that can becombined and reused for defining new services;

agents can directly execute a code through their own workflowmicro-engine or can be configured with the code to be executed accordingto needs to be supported/customised;

the workflow is able to react to external events such as, for example,the automatic measure of vital patient parameters, and in general isable to communicate with sensors and medical devices;

it is possible to execute many workflows simultaneously, and the systemis able to manage interactions and possible conflicts;

agents can advantageously be distributed on user terminals allowing toexecute the service and communication logic with sensors implementedthrough workflows, by locally exploiting the terminal computationcapability;

in order to create clinical protocols through workflows, the xpdlstandard is preferably used, that provides for great advantages in termsof documentability and flexibility;

the system has a high degree of scalability since the use of agents andworkflows allows having and managing computation and decisionalcapabilities at node level (distributed intelligence);

it is further possible to use and manage different and heterogeneousapparatuses, devices and gateways, since agents are open to interactwith different input and output systems;

the system can further be easily interfaced with already existingsolutions in healthcare environments (ex. managing of clinical reports)by using the workflows as explicit and documented mechanism forinteraction between systems and information flows communication.

BRIEF DESCRIPTION OF THE FIGURES

For a better understanding of the present invention, some preferredembodiments of the present invention will be described herein below,with reference in such a description to the enclosed figures, that showthe following:

FIG. 1 shows a teleassistance system according to the present invention;

FIG. 2 schematically shows some components of the system in FIG. 1;

FIG. 3 shows a flow diagram related to activating a service that can bedelivered by the system in FIG. 1;

FIG. 4 shows a flow diagram related to configuring a service that can bedelivered by the system in FIG. 1;

FIG. 5 shows a flow diagram related to a sub-part of the diagram in FIG.4;

FIG. 6 shows the architecture scenario related to delivering a servicethrough the system of the present invention; and

FIGS. 7 to 11 show flow diagrams related to services that can bedelivered by the system of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE PRESENT INVENTION

For the purposes of the present invention, some of its composingelements will be defined below:

Agent: an agent is an autonomous process with an identity, possiblypersisting, that requires communication (for example in a cooperatingand/or competitive way) with other agents in order to execute the tasksthat have been assigned thereto. This communication is implementedthrough the asynchronous exchange of messages and by using a language(called for example Agent Communication Language—ACL) with awell-defined semantics shared within the platform.

Workflow: a workflow is the partial or total automation of a process,during which information or tasks are passed by a participant toanother, in agreement with a set of procedural rules. A workflow can berepresented through a flowchart with a sequence of tasks, mutuallylinked by logic or time dependences such as parallel or alternativepaths. There are ad hoc languages, such as XPDL (XML Process DescriptionLanguage), that allow formally describing the workflows.

Workflow engine: a workflow engine is the component that executes theworkflow descriptions, namely that knows all procedures (workflows) withrelated steps and rules and executes them by determining whether eachone of them can advance to the following step.

Sensor: is a device that transforms the physical quantity that has to beacquired into a typically electrical signal.

Device Gateway: it is an interfacing functionality with sensors forcommunicating patient measures and context information. Suchfunctionality is typically implemented in a mobile or stationaryterminal to be used by the patient.

In a preferred implementation, the system of the present invention,designated as a whole with 1 in FIG. 1, comprises a central platform100, a local system 200 and at least one telecommunications network 300connecting the local system 200 to the central platform 100. Even if inthe present invention reference will be made to a single local system200 for an easy representation, it is clear that the invention can beapplied to any number of local systems, that can be managed by the samecentral platform.

The central platform 100 comprises the following components:

a Graphic Representation System 110;

a Data Storage System 120;

a Workflow Execution Environment 130; and

a Platform Control Environment 140.

The Graphic Representation System 110 comprises:

a Service Creation Environment SCE, namely a software application (ormodule) that allows defining the workflows in a graphic mode;

a Report Console RC, namely a software application that allowsgraphically displaying data collected from patients; this console canfor example be a web-based console (therefore accessible also throughInternet) or a standalone graphic type of user interface (GUI);

an Administrative Console AC, namely a software application that allowsadministering and monitoring the platform through a graphic console.

The functionality of these three components can be made available ondedicated web access gateways by defining ad hoc views, for example:

a Services Centre View, available to third parties that use the platformto offer their own services;

a Doctor View, for displaying and configuring patients/cured people databy the doctor; and

a Patient View, for displaying and configuring their own data bypatients.

The Data Storage System 120 comprises the following set of databases:

a workflow and model database SDB, to store all workflow and modeldescriptions (namely the layout of data treated by workflows, forexample measures, clinical protocols, patient information) of treateddata, that are used by platform components for managing healthcare andwellness services;

an administrative database ADB, for storing administrative data of curedpeople, doctors, third parties, used devices, subscribed services,subscribed polices and SLA (Service Level Agreement) and specificservices data; and

a measure database MDB, for storing measure-related data (for exampleoximetry measures, electrocardiogram (ECG) layouts, blood exam results,alarms for parameters exceeding thresholds), obtained as describedbelow.

The Workflow Execution Environment 130 is a runtime environment thathouses Workflow Executor Agents WEA and manages their life cycle andoperations. Each WEA agent contains a Process Engine PE adapted toexecute workflows, possibly even more than one simultaneously (in anumber that depends on the workload and used hardware resourcesconfiguration).

The platform 100 also comprises components called Adapters anddesignated as AD, adapted to interface the Workflow ExecutionEnvironment 130 with the network 300 (depending on differenttransmission protocols used therein), thereby making the use ofdifferent transmission channels “transparent”.

The Platform Control Environment 140 is a runtime environment thathouses three types of agents:

a Configuration Agent CFA, responsible for controlling the life cycle ofplatforms and in particular responsible for activating, controlling anddeploying agents; in particular, the CFA offers the followingfunctionalities:

-   -   “startup platform”, using a configuration in which agents and        their distribution are specified;    -   “shutdown platform”, through the shutdown of individual agents;    -   activation of Workflow Execution Environment 130 (“start        container”);    -   end of Workflow Execution Environment 130 (“shutdown        container”);    -   startup of a new agent on an existing execution environment        (“startup agent”);    -   end of an agent on an execution environment (“shutdown agent”);    -   display of agent attributes and possibility of modifying some        parameters (for example “pool size”, namely the number of        simultaneously executable workflows);

a database managing agent SDB, designated with SDBA, whose task inparticular is making available the contents of the SDB database andvalidating the workflows; and

a workflow Deployment Agent DA, adapted to receive the workflowsvalidated by the SDBA agent and perform the deploying of such workflows.

The central platform 100 can further be adapted to interact withexternal systems for receiving and sending necessary information fordelivering the services. Interactions are for example possible with thefollowing systems:

a telecommunications functionality (Telco capabilities) system 410,adapted to provide data related to functionalities and applications madeavailable by infrastructures and systems of telecommunications networks,such as for example location data, user presence and profile;

an information system of the healthcare type 420, adapted to connectwith information systems in an healthcare environment;

Service Provider OSS/BSS (Operation Support System/Business SupportSystem) 430, that for example performs service billing if the service isoffered to third parties;

an assistance centre in a medical environment (Medical Centre) 450 (forexample a health assistance centre, a clinic, a consultancy centre,etc.), adapted to provide a specialist service (for example medical orfood consultancy) through the system 1.

The central platform 100 further comprises a data processing module 150,typically a COTS (Commercial Off The Shelf) software, for analysisclinical data, reports (for example electrocardiogram reports), etc.

The local system 200 comprises one or more sensor devices 220 (hereinbelow simply called sensors), to be used by users (for examplepatients), and one or more terminal devices 210 (herein below simplycalled terminals), to be used by the same users or specialised personnel(for example doctors in the same place of patients), adapted to interactwith sensors 220 and to communicate with the network 300; The terminals210 will be identified below also as “nodes” of the local system. Alsothe medical centre 450 can comprise terminals 215, to be used byspecialist personnel, adapted to communicate with the platform 100.

Typically, a user will have a kit of sensors 220 and a terminal 210available. Alternatively, according to the type of service, the terminal210 could be used by nurses or medical personnel in the same seat wherethe user is present (for example an hospital).

The sensors 220 can for example be electro-medical devices DEM,environmental devices DA or “panic buttons” PB. Moreover, the sensors220 can be integrated in the terminals 210, or be separate devices. Inparticular, the sensors 220 can be integrated or associated with morecomplex machines or instruments, such as for example wellness machines(tapis roulants, steps, cyclettes).

Terminals 210 and sensors 220 are able to interact one with the othersfor exchanging data and information (for example measure data, orinformation provided by doctors). If the sensors 220 are physicallyseparate from the terminals 210, the connection can occur for examplethrough a Bluetooth or WIFI, irda, zigbee, wibree interface, orradiofrequency proprietary (“rf proprietary”) solutions.

In an application of the present invention, the kit of sensors 220comprises sensors that are able to detect biomedical parameters (forexample: pressure, temperature, oxymetry, glycaemia, heart rate, weight,percentage of body fat). Preferably, the kit of sensors 220 alsocomprises sensors that are able to detect environmental parameters (forexample: environmental temperature, humidity, height).

Terminals 210 and terminals 215 can be stationary terminals (for examplepersonal computers, stationary videotelephones, medical equipment) ormobile terminals (for example PDA, smartphones, laptops, portableelectro-medical apparatuses). The terminals 210 has also the DeviceGateway functionality, allowing the functionalities implemented bysensors to access the network 300.

The communication between terminals 210 and platform 100 can beperformed for example by using a transmitting channel of the GPRS or SMStype. Adapters AD make the use of different transmitting channelstransparent in the communication between terminals 210 and platform 100.In such communication, the terminals 210 transmit to the platform 100the data coming from the sensors 220 so that such data can be processedaccording to the service logic, for example through WEA agents, and bestored in the measure database MDB.

Preferably, also the terminals 210 comprise a Workflow ExecutionEnvironment 230, similar to the already described one, namely comprisingat least one WEA agent provided with a Process Engine PE, for executingworkflows. Conveniently, if terminals 210 have inside them a workflowengine PE, measure data are locally processed (in terminals themselves)by executing a service logic (implemented as workflow).

Terminals 210 are moreover provided with a graphic console, for examplea web-based console or a stand-alone GUI.

Possibly, also the terminals 215 of the medical centre 450 can comprisea similar workflow environment.

In detail, as shown in FIG. 2, a terminal 210 preferably includes thefollowing components:

-   -   an agent WEA, adapted to communicate with the server part of the        platform 100 and comprising in turn a graphic interface PI        (Personal Interface) through which the user can interact with        the workflow, a set of Widgets WI, namely of graphic components        of interface PI, and a process engine PE for executing        workflows;    -   a device gateway DG, namely a component that is interfaced with        sensors 220 in a wired or wireless mode (for example through the        Bluetooth protocol) in order to find data related to sensor 220        measures and context information (for example environmental        information, patient location, time of the day, type of used        terminal), and possibly notify the alarms.

The components of platform 100 and their functionality can conceptuallybe grouped into three levels: a first services creation level, a secondservices provisioning level, and a third services execution level.

At first level (services creation), the major platform component is theServices Creation Environment SCE, through which it is possible todefine service logics through workflows using, for example, the XPDLstandard.

At second level (services provisioning), the major components are thedatabase SDB, the agent SDBA, the adapter AD and the AdministrativeConsole AC. This level allows making available for executing theworkflows defined through the environment SCE. With reference to FIG.10, the functionalities that can be accessed through the AdministrativeConsole AC and related to this level are:

-   -   a Service Download, namely finding a suitable workflow from the        Data Storage System 120, in particular from workflow and model        database SDB, and its downloading in the Services Creation        Environment SCE through the agent SDBA for managing the database        SDB;    -   a Service Upload, namely the insertion of a new workflow in the        workflow and model database SDB from the Services Creation        Environment SCE through the agent SDBA;    -   a Service Validation, namely the formal check, through the agent        SDBA, that a workflow already inserted in the environment SDB is        executable;    -   a Service Deployment, namely making available a validated        workflow for its execution in Workflow Execution Environments        130 and 230;    -   a Service Removal, namely the removal of a workflow already        inserted in the SDB environment.

The third level (services execution) represents the step of deployingservices by the platform. Such level is arranged for the real executionof previously defined workflows (in the first level), and alreadyuploaded in the SDB environment, validated and deployed (in the secondlevel). The major components of such level are the Workflow ExecutingAgents WEA, that can be deployed on many Workflow Execution Environments(130, 230), that can in turn be deployed, in addition to the platform100, on different nodes 210 of the local system 200 and on possibleterminals 215 of a medical centre 450.

According to an aspect of the present invention, the system 1 user (forexample the patient or the doctor) can interact, through the graphicconsole PI of its own terminal 210. The workflow being executed on theplatform 100 or on the terminal 210 is able to process measures comingfrom sensors 220. If the workflow is being executed on the platform 100,or is being executed on the terminal 210 but it is necessary tocommunicate information to terminals of other users (for example to aterminal 215), it is possible to send asynchronous notifications (fromplatform 100 to terminal 210 or from terminal 210 to other terminals,such as terminals 215) according to modes that can be configureddepending on the implemented service logic. As an example, notificationscan be sent through e-mail, SMS, or phone calls, using the suitableadapter AD. The possible use of Telco services as locating and presenceservices can allow giving a context to transmission of notifications tousers (for example on a fixed telephone if the user is at home, or on amobile telephone if he is outside).

The system 1 of the present invention allows for example implementingthe following types of service (the list is an example and is notexhaustive) within healthcare and wellness environments:

-   -   “home caring” for home assistance when performing a medical        therapy;    -   support to doctor activities during hospital or first aid        assistance activity;    -   teleassistance for elderly patients or patients affected by        invalidating pathologies;    -   teleconsulting and medical cooperation;    -   telemonitoring for patients affected by chronical or temporary        disabling pathologies;    -   tele-first aid and teleassistance for people that are        particularly subjected to illnesses or accidents, such as        elderly or disabled people or children;    -   post-surgery tele-rehabilitation;    -   drug therapy management;    -   work force management in hospital environments or for home        activities;    -   telemonitoring and telemetry of sports exercises in gymnasiums        or open environments (such as sports fields or athletic paths),        with control of physical activity behaviour;    -   telemonitoring services for elderly patients affected by        disabling pathologies, based on environmental parameters and on        patient measures and on subject interaction with the        environment, performed through environmental wireless or wired        sensors.

Some of these services will be described below, as an example.

According to the present invention, in these application environments,workflows are used for:

-   -   defining and implementing the service logic (namely the        application logic performed when providing the healthcare or        wellness service);    -   defining and implementing care protocols associated with every        single patient;    -   defining and implementing the set of activities that realise a        decisional support system to be used by professionals in the        field (for example doctors, nurses, pharmacists) when analysing        and compiling reports.

Interactions with workflows allow notifying alarms (in case, forexample, of vital parameters exceeding a threshold), notifying reminders(in case, for example, of assumption of drugs or the need of performingmeasures), and sending to the patient all necessary information tocomply with the care protocol (for example as regards composition ofmeals). The data displaying console RC moreover allows the doctor (andthe patient) to find and analyse measures performed during the measuringprocess (and stored in the measure database MDB).

Implementing a service requires different steps. Typically, in a firststep, a Services Centre operator defines on the platform 100, by usingthe environment SCE, a set of workflows implementing the service logic,and in particular a workflow that defines the step of activating theservice and the specific workflows of the service itself.

A generic procedure for activating a service, common to all types ofservice, is described below.

Following the purchase of a service by a user (for example bysubscription through internet), the system manager inserts a series ofstarting configuration data (about user and required service) in theAdministrative Database ADB. The user then performs all serviceactivation operations by operating from the (stationary or mobile)terminal 210 or through internet.

The request sent by the user is received by the platform 100 through anadapter AD (for example an adapter AD for https in case of requestthrough internet) and sent to a Workflow Execution Agent WEA of theplatform 100. Such agent WEA activates on its own process engine PE anactivation workflow service for the user, that performs the followingactivities, also schematised in the flow diagram of FIG. 3:

-   -   the user profile (310) is first verified by consulting the        administrative database ADB;    -   if the user is not valid (320), for example in case of wrong        credentials or service not active any more, the workflow is        ended;    -   if the user is valid, its profile is checked (330) on the        administrative database ADB;    -   if the profile is Doctor, a subflow of the Decisional Support        type is run (340) to help the doctor to define therapies with        synthesis about the patient health state and with suggestions        about possible changes;    -   if the profile is Patient, the type of requested service is        verified (350) by consulting the administrative database ADB;    -   according to the type of required service, for example of the        homecaring type or of the telemonitoring type, the Workflow        Execution Agent WEA performs the activation of a related        application (360) (stored in the administrative database ADB)        for the configuration of one or more terminals and one or more        sensors through a suitable adapter AD, and on the terminal 210 a        related subflow is run (370), for example of the Homecaring        Configuration or Telemonitoring Configuration type.

With reference to FIG. 4, the telemonitoring service configurationsubflow (Telemonitoring Configuration) initially waits that theconfiguration of terminal 210 and kits of sensors 220 available to thepatient is ended (415). Such configuration can include, for example, theactivation on terminal 210 of the agent WEA and the gateway DG towardsmedical devices, and the Bluetooth pairing between gateway DG andsensors 220.

If the configuration step is not successfully ended, the subflow isended.

If the configuration is successfully ended, the confirmation of theperformed configuration is sent to the subflow through a communicationbetween Workflow Execution Environment 230 on terminal 210 and agent WEAof the platform 100 on which the subflow runs, through a suitableadapter AD.

The configuration subflow then goes on with the following steps:

-   -   configuration of reference doctors for the patient (420) within        the administrative database ADB (by an operator or automatically        if pre-assigned);    -   configuration of Medications and Measures agendas that allow the        reference doctor to plan measures and drug administrations that        the patient must perform during the day and the reference        thresholds for measures that will be performed by the patient        (435);    -   activation in a parallel and asynchronous way of two Medications        and Measures subflows for managing patient medications and        measures (440).

These subflows, according to the service configuration, can be executedlocally on platform 100 or remotely on patient terminal 210.

The two subflows run at the end of the configuration are those thatpractically implement the service required by the user and are marked bythe interaction with the user itself.

The Measures subflow is described below with reference to FIG. 5. Thesubflow performs the following steps:

-   -   initially, the subflow remains waiting (510) for receiving        patient measures or modification notifications from measures        agenda;    -   if the measure is not received within the foreseen times, a        notification is sent to the patient (520), for example through        SMS, by using the suitable adapter AD according to the service        configuration;    -   if the measure is received within the foreseen times, the        subflow processes the data (530), enters them in the measure        database MDB and, if provided by the service configuration,        sends notifications to the doctor for measures that exceeded the        pre-established reference thresholds for the patient, for        example through SMS and/or through a suitable signalling on the        data displaying console RC;    -   as regards the measures agenda, the subflow initially finds in        the administrative database ADB the measures agenda (previously        entered at configuration level and/or modified by the doctor)        and self-configures depending on such agenda; in case of        reception from workflow of a measures agenda modification        notification that allows the doctor to modify the agenda, the        subflow is reconfigured depending on new parameters (540);    -   the END block represents the measures deactivation.

The Decisional Support block 340 of FIG. 3 is described below withreference to FIG. 11.

The doctor accesses the patients information monitored by him andverifies the global patient state verifying measure data and associatedagendas (1110).

If there are measure values exceeding a threshold, the doctor analysesthe global behaviour of measures performed by the patient through a dataanalysis software and possibly queries and consults similar historicaldata as support for actions to be performed (1120). If he deems itsuitable, the doctor modifies the patient therapy and the medicationsagenda (1130).

If there are measures requiring filling of reports, the doctor analysesthe measure data with the automatic analysis and report filling software(1140) and, depending on performed processing and measure, writes thereport (1150) that will be recorded in the measures database MDB.

Supposing that the telemonitoring service is dedicated to patients withchronic pathologies (for example diabetic, cardiopatic, asthmaticpeople, etc.), the service allows periodically communicating (asprovided in step 530) to a medical centre 450 the value of some measuredparameters (for example glycaemia, blood pressure, weight, bloodsaturation, daily diet, etc.). The caring doctor can thereby perform theanalysis of received measures, monitor the behaviour of a possibletherapy and activate possible corrective actions (ex. insulin dose ordiet variation).

The platform 100 is adapted to execute an instance of the previouslydescribed workflow for every patient that has activated the service.Moreover, at any time when deploying the service, the telemonitoringworkflow can be modified by a Service Centre for adapting it to newrequirements.

As previously mentioned, a further service that can be deployed is thehome caring service for home assistance when performing a medicaltherapy. Such scenario is shown in FIG. 6, where a plurality ofterminals 210 can be seen, associated to respective kits of sensors 220and to respective devices for controlling environmental parameters (forexample a conditioner) 230; all these devices are typically used byrespective patients in respective houses 240A, . . . ,240N. Theconnection between devices for controlling environmental parameters 230and terminals 210 can be of the wired or wireless type. The system alsocomprises the network 300, the platform 100, and a medical centre 450 inwhich a further terminal 215 is arranged to be used by a doctor. Wiredconnections are represented with a continuous line, while wireless oneswith a dashed line.

In such scenario, doctor and patient agree about a therapy, that forexample includes: pharmacological dosing (for example the value ofinsulin to be assumed), diet, planning of measures (for exampleglycaemia, blood pressure, weight, etc.). The doctor, by using theServices Creation Environment SCE of the platform 100, accessiblethrough the console RC, and with the help of the Services Centre 440,defines the workflow corresponding to the specific care plan for thepatient. The thereby arranged workflow is made available through aServices Provisioning process as previously described.

The step of activating the service is analogous to what has beenpreviously described. In this scenario, the terminal 210 used by thepatient (for example a cellular phone) performs both the function ofGateway DG and the function of platform node with Workflow ExecutionAgent WEA. Moreover, processing of data measured by sensors 220(electro-medical devices, environmental devices, etc.) is performedlocally without the need of involving the rest of the platform,exploiting the terminal computation capability.

FIG. 7 shows a possible workflow of a home caring service for diabeticpatients, in a scenario as shown in FIG. 6. The patients are equippedwith sensors 220 of the medical type (DEM) for measuring glycaemia anduser terminals 210 that are able to execute the workflow and to interactwith medical devices 220. In the workflow, computation logics areimplemented for insulin dosing depending on measures of glycaemia valuesand the indication by the patient about foreseeing macro-nutriments ofthe meal that will be assumed. In detail, the workflow performs thefollowing steps:

-   -   the workflow being executed on the patient terminal 210 remains        waiting for receiving the pre-meal glycaemia measure (710);    -   if the measure does not arrive within a pre-established time,        the workflow takes care of generating a wrong measure message        for the patient (715);    -   when the measure is performed through the DEA sensor (a glucose        meter in the specific case), measure data are sent through        bluetooth by the DEA sensor to terminal 210 through the Gateway        DG (720);    -   the workflow remains then waiting for receiving the forecast of        division of meal macro-nutriments (for example forecast of        carbohydrates), that the patient will have to enter through the        PI interface of the agent WEA being executed on terminal 210        (730);    -   on the patient terminal 210, the indication of the insulin dose        to be assumed is then displayed (740), established depending on        previously processed data;    -   the workflow then remains waiting for receiving the post-meal        glycaemia measure (750);    -   if the measure does not arrive within a pre-established time,        the workflow takes care of generating a wrong measure message        for the patient (755);    -   when the measure is performed through the DEA sensor, the        measure data are again sent through bluetooth by the DEA sensor        to terminal 210 through the Gateway DG (760);    -   depending on post-meal measure results, possible corrective        actions will moreover be signalled to the patient (770).

As already previously described, the workflow defining the patientmonitoring protocol can also interact with sensors of the DA(environmental devices) type that measure environmental parameters (suchas temperature and humidity inside the house, barometric pressure,altitude, etc.), devices equipped with Panic Button PB and devices forcontrolling environmental parameters 230 (for example a conditioner forchanging a room temperature). In this latter case, the correctiveactions present at the end of the workflow (770) can comprise anautomatic interaction between terminal 210 and devices 230 to adjustenvironmental conditions according to pre-established rules linked topatient conditions, for example by lowering or increasing temperatureand/or humidity.

The doctor can anyway change at any time the patient care protocol byusing services provisioning functionalities of the platform 100,previously described.

The present invention moreover allows, as already previously mentioned,to perform services supporting the doctor. The doctor can be helped whenassisting the patient through a workflow that, being executed on its ownterminal, operates as his assistant by analysing data received frompatients and performing a first diagnosis. The workflow moreover canactivate evolved data analysis software automatically for the followingdoctor analysis.

The workflow in particular is adapted to send notifications to thedoctor upon receiving (from the sensor device 220) vital patientparameters that are out of range, to suggest a change of therapy ortelemonitoring parameters (for example a measure frequency, or a warningsetting modification), and to perform the analysis of received measuresby activating third parties' software (for example graphicelectrocardiogram processing).

The present invention moreover allows deploying services related to thewellness sector, such as for example telemonitoring of vital parameters(ex. heart rates, breathing frequency) during sports training, dailydiet management, and telemonitoring of daily calories consumption. Forexample, the use of workflows allows analysing, for every user, servicesto suit the daily diet to the daily calories consumption, or to makeavailable for an athlete the value of his own bio-physical data whentraining.

Herein below a service is described for defining the diet depending onthe daily calories consumption, and therefore the performed physicalactivity. The service, for every user, comprises the definition of a“diet” plan by a dietist that, for every day of the week, provides forthe type of foods and their related amounts to be assumed and theforeseen calories consumption; the telemonitoring of daily caloriesconsumption through a device worn by the user; and the dailytransmission of correct diet information to the user. This service isperformed by using the workflow shown in FIG. 8, being executed on theuser terminal 210.

As starting data, the diet plan is set (810) provided by the doctor andstored in the administrative database ADB. The workflow being executedremains then always waiting for receiving measures about caloriesconsumption. Such measures can be performed at pre-established timeintervals. The terminal 210 is arranged for interacting through thegateway DG with sensor 220 that measures the calories consumption andthat is worn by the user. Depending on an agenda established at acertain time of the day, the received measures will be processed and thediet plan will be updated and made available to the user on theterminal. More in detail, the workflow verifies whether the measuredcalories consumption (instantaneous or integrated) is compatible withthe current diet plan (830). If the calories consumption value fallswithin the range provided by such plan (output NO from block 830), theworkflow goes on by proposing a daily diet to the user (840). If insteadthe calories consumption value is outside the range provided by the dietplan (output YES from block 830), the workflow suitably modifies thediet plan (840) taking into account the new calories consumption andsends it to the user (850). The workflow the returns waiting forreceiving a new measure.

A further possible service is the telemonitoring service for elderlypatients affected by disabling pathologies. Such service is aimed tostructures for health assistance of not self-sufficient elderly peoplesuch as for example the RSA (Residenze Sanitarie Assistite—AssistedHealth Residences) in which the elderly person is provided with acontinuous (day and night) assistance by responsible personnel. For suchpurpose the structure personnel is provided with terminals 210, of thestationary or mobile type.

In this service, a set of environment sensors DA are used, pre-arrangedin the structure rooms of interest, that allow for example monitoringtemperature, air quality, light and one or more DEM sensors beingpresent on the patient, that allow for example monitoring hearth rate,body movements, and location.

All signals coming from sensors are collected in the measure databaseMDB and the structure personnel has access to data through thedoctor/services centre operator view and can therefore keep structureand housed patients under control.

The service operates as follows. By using the Services CreationEnvironment SCE, the Services Centre 440 defines a set of workflows thatimplement the service logic and in particular the workflows implementingthe various emergency and intervention situations on the assistedperson.

For example, it is possible to locate a critical situation by a patientthat remains in bathrooms during the night for more than 30 minutesstationary with the light on. Such situation is managed with a portionof workflow shown in FIG. 9 and described below. Such portion ofworkflow uses DA sensors that measure lighting of different rooms and DAsensors that measure patient movement and location.

Variations of these sensors are traced in the measure database MDB andshould a situation occur with presence of a patient in a bathroom duringthe night with light on and no movement signal, a timer is set in theworkflow, depending on information stored in the administrative databaseADB. Upon expiry of the maximum provided time, if no variation occurred,an alarm is signalled to the operator.

In this case the workflow is being executed on the platform and usesboth environmental measures and measures related to the patient bycombining them together for detecting critical situations.

In detail, the portion of workflow operates as follows:

-   -   the workflow periodically verifies (at very short intervals) the        three parameters of location, movement and lighting and compares        them with the three statuses representing the situation deemed        as critical, namely location=bathroom, movement=unmoving and        light=on; the workflow remains waiting till the three statuses        simultaneously occur (910);    -   when the three above statuses occur, the workflow activates a        timer for a pre-established time (ex: 30 minutes) and remains        waiting either for a variation of one of the three parameters or        for the timer time-out (920);    -   if there is a variation of one of the statuses, the timer is        deactivated (930) and the workflow returns to the starting        waiting status;    -   if the pre-established time expires without a status variation,        an alarm signal is activated for the operator (940).

1-32. (canceled)
 33. A method for performing a teleassistance service, comprising: executing a measure of at least one biomedical parameter on a service user; and executing, through a software agent, at least one workflow associated with the service and defining a process interactive with the measure execution.
 34. The method according to claim 33, comprising transmitting information related to a result of the measure to a remote system through a telecommunications network.
 35. The method according to claim 33, further comprising providing the user with a feedback based on a result of the measure.
 36. The method according to claim 35, wherein the software agent is in a terminal.
 37. The method according to claim 35, wherein the software agent is in a remote system.
 38. The method according to claim 33, comprising the preliminary steps of defining the workflow in order to implement a service logic, and of storing the workflow in a database.
 39. The method according to claim 36, comprising receiving a service request by a user, and executing, in reply to the service request, a service activation workflow in a software agent, and wherein executing an activation workflow comprises selecting the workflow associated with the service among a plurality of available workflows, depending on information contained in the service request.
 40. The method according to claim 39, wherein executing the activation workflow comprises transmitting the selected workflow to the terminals.
 41. The method according to claim 39, wherein executing the activation workflow comprises configuring the terminal to adapt the terminal for executing selected workflow.
 42. The method according to claim 41, wherein the software agent is in the terminal and configuring the terminal comprises activating the software agent in the terminal and activating a connection between the terminal and a sensor.
 43. The method according to claim 33, further comprising the step of executing a measure of at least one environment parameter related to an environment in which the user is located, and defined by the workflow being interactive also with the execution of the measure of the at least one environment parameter.
 44. The method according to claim 33, further comprising the step of executing a user location measure, and defined by the workflow being interactive also with the execution of the location measure.
 45. A system for performing a teleassistance service, comprising: a central system capable of controlling and managing the service; a local system capable of executing the service; and a telecommunications network capable of being adapted to communicate the central system with the local system, wherein the local system comprises at least one sensor capable of being adapted to perform measures of at least one biomedical parameter on a user and a terminal capable of being adapted to communicate with the sensor to receive information related to the measures; and wherein at least one of the terminal and the central system comprises a software agent provided with a process engine capable of executing workflows, said agent capable of being adapted to interact with the sensor with executing workflows.
 46. The system according to claim 45, wherein the terminal is capable of being adapted to transmit said information to the central system through the telecommunications network.
 47. The system according to claim 45, wherein the terminal comprises said agent and a graphic interface through which the user can interact with the workflows.
 48. The system according to claim 45, wherein the terminal comprises a device gateway for communicating with the sensor.
 49. The system according to claim 45, wherein the terminal and the sensor are capable of being adapted to mutually communicate through a wireless connection.
 50. The system according to claim 45, wherein the central system comprises a graphic representation system capable of creating workflows.
 51. The system according to claim 45, wherein the central system comprises a data storage system for storing workflows and results of said measures.
 52. The system according to claim 45, wherein the central system comprises a plurality of workflow executing agents, each agent comprising a process engine for executing workflows.
 53. The system according to claim 45, wherein the central system comprises a plurality of adapters capable of interfacing a plurality of workflow executing agents with the telecommunications network, depending on transmission protocol.
 54. The system according to claim 45, wherein the central system comprises a workflow deploying agent.
 55. The system according to claim 45, wherein the local system comprises at least one environment sensor capable of being adapted to measure an environment parameter, said agent capable of being adapted to interact with the environment sensor when executing workflows.
 56. The system according to claim 45, comprising at least one further terminal capable of being adapted to communicate with said terminal through the central system and the telecommunications network.
 57. The system according to claim 45, wherein the sensor is integrated in the terminal. 